\section{Comparaci\'on }

En esta secci\'on compararemos algunos de los temas vistos en la materia. Lo haremos por un lado en general, teniendo un cuenta sus usos y objetivos, y por otro lado de acuerdo a nuestra experiencia con ellos en los distintos trabajos pr\'acticos de la materia.

\subsection{Metodolog\'ias de trabajo - \'Agil vs UP}

La elecci\'on de la metodolog\'ia de trabajo de un proyecto es una parte fundamental al momento de definir su plan. Cada metodolog\'ia tiene caracter\'isticas distintas que hacen que sean de mayor o menor ayuda de acuerdo a las caracter\'isticas de cada proyecto. No hay balas de plata en las metodolog\'ias de trabajo, cada una tiene objetivos y sus caracter\'isticas particulares. Por esta raz\'on es importante seleccionar la metodolog\'ia mas apropiada para cada proyecto que encaremos ya que el \'exito de \'este puede estar influenciado por la elecci\'on de la metodolog\'ia.

Mencionaremos algunas caracter\'isticas de los proyectos y veremos como pueden influir en la elecci\'on del m\'etodo de trabajo.

\begin{description}
\item[Cambios en los requerimientos] Pese a que pr\'acticamente todos los proyectos experimentan cambios en los requerimientos en y/o debido a su desarrollo, hay algunos proyectos que cambian m\'as que otros. Los planes de algunos clientes est\'an mas cerrados o claros que otros. Las metodolog\'ias \'agiles ayudan a los clientes a ir refinando sus requerimientos, ya que son capaces de ver prototipos de sus ideas pronto, de forma de evaluarlas y definir si se adec\'uan a sus necesidades o si necesitan alg\'un cambio. Al no tener documentaciones extensas ni planes cerrados, es mucho menos costoso cambiar algun aspecto de los requerimientos, ya que no genera retrabajo en la modificaci\'on de estos requerimientos. Los modelos como UP requieren que varios de los requerimientos est\'en fijos desde el inicio, para poder planificar y asignar recursos con mayor  seguridad y, pese a que al adoptarse en general en un desarrollo iterativo incremetal contemplan la posiblidad de cambios, es mucho m\'as sencillo introducirlos  si se trabaja con metodolog\'ias \'agiles.

Otro aspecto que puede influir es que debido a que las iteraciones suelen ser m\'as cortas al usar metodolog\'ias \'agiles los distintos features se pueden mostrar m\'as r\'apido a los clientes.

En conclusi\'on UP requiere un esfuerzo inicial en identificar los requierimentos que no siempre es posible o no vale la pena hacer.

\item[Equipo de Trabajo]  Las metodolog\'as \'agiles se adec\'uan mejor a equipos de trabajos chicos. Con m\'as de 10 personas en un equipo se dificulta realizar las daily meatings y las IPs. Tambi\'en puede haber problemas si los equipos est\'an geogr\'aficamente distribuidos o si los miembros del equipo tienen seniorities distintos o si no todos ellos pueden realizar cualquier tarea.

\item[Necesidad de planes precisos]  Algunos proyectos, debido a sus inversores o a la relaci\'on de (poca) confianza entre el cliente y la empresa desarrolladora, requieren  un plan detallado con la estimaci\'on del tiempo que llevar\'a implementar cada feature. Por supuesto, este item est\'a bastate relacionado con el primero, en el sentido de que no se puede tener un plan detallado si los requierimientos no est\'an claros. \'Este tipo de proyectos suelen ajustarse m\'as a una metodolog\'a del tipo UP, ya que  UP suele generar un plan preciso con asignaciones, tiempos y tareas.

\item[Tama\~no del proyecto] Los proyectos grandes suelen funcionar mejor con metodolog\'ias como UP, esto se debe principalmente a que suelen necesitar equipos grandes y a que suelen tener la necesidad de un plan mas detallado.

\item[Prototipos funcionales] Si el proyecto puede cancelarse en cualquier momento o si el presupuesto no es fijo o conocido desde un principio, puede ser m\'as \'util para los clientes y para la empresa desarrolladora trabajar con metodolog\'ias \'agiles ya que al final de cada iteraci\'on generan un producto potencialmente shippable. Esto no necesariamente es as\'i para desarrollos usando UP. 

\item[Complejidad-Escala del proyecto] En sistemas en la que la disponiblilidad o la performance son trascendentales, suele ser muy \'util definir y probar una arquitectura al inicio del proyecto. Dado que UP hace un gran an\'alisis de requerimientos y asigna una parte importante del proceso a definir la arquitectura, puede ser mejor usar UP en \'estos casos.

\item[Documentaci\'on] Algunos proyectos requieren documentaci\'on de avance, de c\'odigo, de procesos o de otros tipos. Las metodolog\'ias \'agiles no contemplan en su forma m\'as pura la generaci\'on de documentaci\'on y en cambio en UP suelen ser m\'as frecuentemente generadas.

\item[Formalidad del cliente] Algunos clientes grandes tienen un proceso de desarrollo muy formal y estructurado. Con ellos es bastante dif\'icil lograr que se inclinen por una metodolog\'ia de trabajo m\'as liviana como las metodolog\'as \'agiles. \'Esto muchas veces se debe a que nuestro cliente directo muchas veces debe reportar alcance y avance del proyecto de una manera formal a sus superiores, lo cual es m\'as dif\'icil de hacer cuando se usan metodolo\'ias \'agiles.

\item[Tipo de contrato] Si se trabajo con proyectos con presupuesto o scope fijos puede ser recomendable usar metodolog\'ias como UP ya que fijan desde el principio el alcance del proyecto. 

\item[Experiencia del equipo de desarrollo] Si el equipo de trabajo est\'a acostumbrado a trabajar con una metodolog\'ia en particular, puede ser contraproducente cambiarla. El tiempo en adaptarse a la nueva metodolog\'ia  o el haberla impementado de forma incorrecta puede retrasar el proyecto.

\item[Compromiso y dedicaci\'on del cliente] Las metodolog\'ias agiles requieren que el cliente este disponible para el equipo de desarrollo durante gran parte del proceso. Si el cliente puede hacer esto es recomendable y aporta mucho valor usar metodolog\'ias \'agiles. Si el cliente s\'olo tiene un tiempo fijo en el inicio del proyecto para definir el alcance y al final del proyecto para probarlo y dar su conformidad, suele ser mejor definir lo m\'as posible al inicio y usar alguna metodolog\'a como UP.

\item[Criticidad del proyecto] Dependiendo del impacto de los defectos de nuestro proyecto, puede ser mejor usar alguna metodolog\'ia m\'as rigida como UP. Si se pierden vidas o mucho dinero si nuestro software no se adapta a los requerimientos, suele ser mejor usar UP. Esto se debe fundamentalmente a que en estos casos los requerimientos suelen (o deben) estar muy claros desde el inicio y es muy importante que el desarrollo se adec\'ue muy bien al plan.

\end{description}

Para concluir diremos que tanto UP como las metodolog\'ias \'agiles tienen como objetivo ayudar a definir el producto a concluir. Esto se debe a que la mayor\'ia de los proyectos que fallan lo hacen por problemas de no adecuaci\'on de las necesidades del cliente con el producto construido (es decir problemas de requerimientos). Las principal diferencia entre ambas es la manera en que se ocupan de lograr este objetivo. Las metodolog\'ias m\'as pesadas como UP optan por tener la mayor cantidad de cosas definidas y claras desde un principio y de definir y manterse dentro de un plan que permita cumplirlas (por supuesto tambi\'ien permiten cambios si es que se enmarcan dentro de un desarrollo iterativo incremental, pero los cambios de requerimientos hacen que el plan de trabajo deba cambiar). En cambio las metodolog\'ias \'agiles se enfocan en permitir e incluso impulsan el cambio. La elecci\'on de una o la otra deberia deberse a las caracteristicas del ambiente, el proyecto, el cliente y el equipo de desarrollo.

\subsection{Programming in the small vs programming in the large}

El diseño de objetos y el diseño de la arquitectura son instancias diferentes un proceso de desarrollo. Haremos un punteado de caractect\'isticas y diferencias de cada uno de ellos.

\begin{description}
\item[Momento en el desarrollo] El diseño de objetos suele hacerse en el d\'ia a d\'ia de la programaci\'on. El diseño de arquitectura suele hacerse principalmente al inicio del proceso de desarrollo.

\item[Roles] Diseño OO lo hace cada programador en cada feature que implementa. La arquitetura la define el arquitecto.

\item[Reviews] Ambos diseños deben ser revisados, en el caso de OO pueden hacerse code reviews con otros pares programadores y en el caso de arquitecturas, la arquitectura puede checkearse con otros arquitectos expertos.

\item[Impacto] Tanto problemas en el diseño como problemas en la arquitectura pueden hacer que el proyecto falle. Ambas son igualmente importantes, pero probablemente un problema en el diseño pueda ser solucionado m\'as r\'apido que un problema en la arquitectura. Aunque por supuesto depende del problema y del estad\'io de desarrollo.

\item[Concern] Al diseñar arquitecturas pensamos definir los  componentes del sistema, al diseñar objetos pensamos en estructurar el c\'odigo.

\item[Objetivo] Al diseñar la arquitectura definimos el sistema en base a los atributos de calidad buscados. Al diseñar objetos definimos el c\'odigo en base a funcinalidades y buenas pr\'acticas.

\item[Duraci\'on] El diseño de un solo feature suele llevar poco tiempo. El diseño de Objetos de un sistema suele ser producto de  distintos diseños de feature unidos m\'as refactors. El diseño de arquitecrtura suele realizarse una s\'ola vez y cambiar m\'as eventualmente. 
\end{description}

Para concluir diremos que programming in the small y programming in the large son enfoques distintos para un proceso de desarrollo que se dan juntos en todos los desarrollos. Algunas veces el diseño de arquitectura suele estar oculto ya que se usan soluci\'ones predefinidas. Pero es muy importante ser conscientes de que en todo desarrollo estamos definiendo una arquitectura que es adecuada para cierto escenario y cietos atributos de calidad.


\subsection{Nuestras conclusiones}

Luego acercarnos a distintas metodolog\'ias y a distintos enfoques de programaci\'on diremos principalmente que nos gust\'o mucho y nos resulto muy \'util haber pasado por estas instancias.

En el caso de las metodolog\'ias nos gust\'o mucho entender en qu\'e casos son apropiadas cada una de ellas y que no hay una mejor que la otra. Sobre los tps, nos pareci\'o que tal vez hicimos m\'as incapie en usar a fondo metodolog\'ias agiles y en el caso de UP se vio m\'as en teor\'ia pero no lo aplicamos en todo el proceso de desarrollo (por ejemplo en la forma de estimar, etc).

En el caso del diseño de Objetos y Arquitectura nos parece que ambos son fundamentales en todo proceso de desarrollo y nos gust\'o mucho poder hacer diseños para ambas. Particularmente, casi todos nosotros trabajamos en muchos proyectos distintos y nunca nos hab\'iamos puesto a pensar tan en detalle en la arquitectura o incluso a veces en patrones de objetos.

Nos hubiera gustado (como si hicimos con diseño OO) implementar alguna parte de nuestra arquitectura usando elementos predefinidos de software (como colas de mensajes, o bases de datos) pero entendemos que probablemente no hubiera habido tiempo en la materia.



